Service Oriented Architecture (SOA) is a popular building block for open-standards based information technology (IT) today, see, e.g., E. Newcomer et al., “Understanding SOA with Web Services,” Addison Wesley (ISBN 0-321-18086-0), 2005, the disclosure of which is incorporated by reference herein. In general, as is known in computing environments, SOA provides a set of governing concepts used during phases of system (e.g., application) development and integration. Such an architecture packages functionality as interoperable services. Software modules provided as a service can be integrated or used by several domains and/or enterprises, even if their respective client systems are substantially different. Further, it is known that, rather than defining an application programming interface (API), SOA defines the interface in terms of protocols and functionality. Still further, SOA separates functions into distinct units, or services, which developers make accessible over a network in order that users can combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.
In the context of intra- and inter-enterprise service connectivity, service domains can be defined that delimit the visibility and connectivity for collections of services and within which services can display Enterprise Service Bus (ESB) properties, including dynamic selection and location transparency. As is known, ESB is a software infrastructure that facilitates application integration and may be used to implement an SOA. While ESB technology is well-known in the art, general reference may be made to the text: David A. Chappell, Enterprise Service Bus, O'Reilly, 2004, the disclosure of which is incorporated by reference herein. The ESB property known as dynamic selection allows the provider of a service to be selected at request time via mediated late binding. The ESB property known as location transparency allows provider services to change their endpoint address without impacting requester services. A service domain may be realized in terms of one or more ESBs, such as WebSphere ESB (Websphere is a trademark of International Business Machines Corporation, Armonk N.Y.). A service domain relies on a service registry, defined within the domain's scope, to keep track of services within its scope, and to provide ESB properties.
In this context, federations can be defined as aggregate service domains that allow connectivity of services across service domains via the introduction of service proxies. A service proxy is a service connectivity artifact that allows services to communicate across domains. A service domain federation cannot be assumed to define a single, centralized service registry. A further assumption is that it is not desirable for each service domain registry to contain entries for every service in every domain in the federation. Thus, if a service provider moves across domains, connectivity must be re-established by re-introducing proxies to the service provider's new location into every domain where an interested service requester exists.